Hizumi Mizushiro
Earth Alliance Expeditionary Force
1
   |
Posted - 2015.07.27 17:12:52 -
[1] - Quote
I'm surprised no ones figured this out yet; Theres a relatively simple workaround / solutions which could be implemented by CCP with relative ease. I've been using this since the problem occurred in Scylla.
Since the migration to the shared cache in Scylla, not only was the multi client cache shared into one directory, the wine socket was also put into the shared directory, which is the crux of the issue.
Launching multiple clients will reuse the wine socket, which is not a problem.
Closing one of those clients also closes the socket, so when other clients try to read/write to the socket, they appear to be dead.
Best i can figure the reason why the wine server appears stuck and needs to be kill -9'd in order to relaunch it is because its counter of open clients != closed clients, so the process remains active (though it could just be another problem related to an incomplete socket.close() call).
Workaround as follows:
- Open launcher
- Launch Client 1
- Navigate to shared Cache DIrectory [ ~/Library/Application Support/EVE Online ]
- Locate a directory named similar to wineserver-uuid-username
- Rename it to whatever you want
- Launch Client 2
- ???
- Profit!
The launcher will always regenerate the original folder name on every client launch, so any number of clients can be launched via this method by simply renaming the regenerated folder to a new name.
I have no idea why the generated uuid in the directory name is the same every time, it appears to be a mac address, but it doest match any of my interfaces.
Quick CCP solution would be to actually generate a uuid in the directory name on client launch + socket creation vs reuse of same socket.
Proper CCP solution would be to cross check whether it should actually run socket.close() on client quit if multiple clients are open vs just a deallocate ( Disclaimer: I know jack about how wine internals actually work )
Sorry for keeping this a 'secret' for so long. I honestly thought others had figured this out by now since it has been nearly 4 months.
=== CAVEAT ===
Almost forgot to put this in:
DO NOT OPEN IGB
IGB seems to do voodoo to the socket to generate a new window, but it cannot connect to the socket since the directory has been renamed ( doesn't affect game since socket was already open and fs changes on an os level won't affect data read/write ) |